In a component-based business data processing environment, there are typically mixtures of data processing activities in a system at any one time. These activities may have complex relationships and interdependencies, and the management of their deployment and life-cycles can be difficult and time-consuming for the system designer and programmer. To ease this management task, components (typically instances of objects in an object-oriented environment) are normally grouped in classes, with each object in a class having the same characteristics as all others in its class. It is well-known in the art to have objects in classes with common run-time characteristics determined at the class level.
In such an environment, the life-cycle of a component normally follows the typical pattern of the life-cycle of an instance of an object in an object-oriented environment. That is, each component belonging to a particular class takes its characteristics from the class. Normally, the management of a component's life cycle is predetermined by settings given to the class of which it is a member.
An example of such an environment is an Enterprise Java Beans environment, in which Java Bean components are provided with deployment descriptors which contain settings to determine the characteristics of each instance of each Java Bean. When used as a business processing environment, the Enterprise Java Beans represent business activities which may be linked together in sequence, or sometimes executed in parallel, to perform business processing on behalf of client programs. Such an environment is described in Enterprise Java Beans Technology, by Anne Thomas (published by Patricia Seybold Group), which is herein incorporated by reference. In such an environment, the degree of abstraction of the process of combining flexible components into a real-world runtime information processing system renders the problem of the detailed control of individual data processing elements and all their relationships with heterogeneous resources, extremely difficult.
A business model can be defined by a set of nested communicating business activities. Each activity performs a specified function based on the message it is passed when another activity communicates with it. One basis of such models is that each activity has no knowledge of the activities that it communicates with; it simply receives an input message and, when appropriate, generates an output message. The way the activities are wired together is defined in the business model and does not affect the processing of the activity.
An activity may be defined as an object that responds to one or more messages, which has runtime characteristics and state data, and which responds to a received message by performing some processing and producing an output message. Both the input and output messages are strictly defined for each activity. Such activities can be nested. That is, a first activity can initiate a second activity which performs processing on behalf of the first activity and then returns control to the first activity.
Each activity has associated with it certain characteristics by which it may be controlled. It is known in the art to have components which have built-in mechanisms for managing themselves at run-time. Examples of such components are the Enterprise Java Beans already discussed, each of which has a deployment descriptor determined by the class of which it is a member. Deployment descriptors typically contain information that permits an activity to be, for example, recoverable, or to permit it to form part of a transactional entity so that its updates to a database may be coordinated with those of other transactions in the system. In the Enterprise Java Bean environment, the client creates beans (instances) when they are needed for a particular processing action, and destroys them when they are no longer needed for the particular processing action. This can be wasteful in its consumption of resources: where many clients are initiating and terminating processing in a busy environment, the system can be consuming considerable processing resource in the creation and destruction of these instances. Such an environment is also rather rigid in that a whole class of beans must have the same deployment characteristics.